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DESCRIPTION 
hfethod and Bvsfccgn for gecurelv inanaalna EEPRQM data files 



FIELD OF THE IimiNTION 

This invention generally relates to improvements in the 
management of EEPRQM data files and more particularly to the 
secure management of data files in EEPRQM memory space of chip 
cards in case of interrupted write cycles. 

BACKGROUND OF THE INVENTION 

Chip cards are getting more and more wide-spread in various kinds 
of application fields, such as telephone cards, banking cards, 
credit cards, ID-cards, insurance cards etc. In addition to the 
sophisticated identification and authentication mechanisms which 
they contain, chip cards are often used as data storage device* 
In typical processes and operations of chip cards, such as 
payment operation, authorisation processes etc., data stored in 
the chip card has to be altered. In the following, such processes 
and operations are called "transactions"* 

In a high number of the transactions performed with a chip card, 
parts of the software contained in the microcontroller of the 
chip card have to be performed completely or not at all. A 
sequence of operations which cannot be split up (and which can 
therefore only performed in full or not at all) is called an 
atOKtic sequence of operations* Atomic sequences of operations 
always occur in EEPRQM write routines. Atomic sequences are based 
on the thought that in write cycles of the EEPRQM it has to be 
ensured that the concerned data is not only written partially. 
This can occur, for example, if the user of the chip card 
withdraws the card from the terminal during the write process, or 
if there is a power failure* A secure management of the EEPROM 
write data is particularly essential if the chip card is used as 
electronic purse (e-cash> as the chip card has to be a reliable 
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payment device for the user, and because especially in payment 
transactions, data contained in multiple files has to be altered 
5 imul taneous 1 y ♦ 

In these cases ; the operating system of the chip card has to 
ensure that the consistency of all data is guaranteed when the 

chip card is energlized again after an interrupted write process. 

i 
I 

At present, chip cards contain baclcup buffers in their EEPROMs. 
This buffer is large enough to store all necessary and relevant 
data and comprises a flag indicating the status. The flag can 
either be set to "data in the buffer valid" or to "data in the 
buffer not valid*** Additionally, an according memory for the 
destination address and the actual length of the buffer data must 
be provided. In operatioHi data in the destination address is 
copied into the buffer, together with their physical address and 
length. The flag is set to ''data in the buffer valid". In a next 
stepr the new data is written at the desired address, and the 
flag is set to "data in the buffer not valid". When starting up 
the operating system before the ATR (answer to reset) , the flag 
is checked* In case It is set to "data in the buffer valid" » 
there is an automatic writing of the data contained in the buffer 
at the equally stored address. 

With this mechanism, it is ensured that valid data is contained 
in the file, and in case of program interruption, the data in the 
EEPROM of the chip card can be restored. 



However, the known method of using a backup buffer has several 
disadvantages. First, the buffer size has to be at least as large 
as the data to be buffered, and has to be reserved in the EEPRGM 
of the chip card. As EE PROM space is expensive and has to be 
available on the. card in a sufficient size in order to store all 
relevant data for the user, the buffer cannot be arbitrarily 
large. Therefore, the amount and size of the data to be buffered 
is limited. Second, due to frequent writing and erasing of data, 
the buffer is subject to high-duty service and therefore 
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excessively stressed^loaded. As the number of write/erase cycles 
of the EEPROM is limitedr there is the risk that a writing 
mistake occurs in the important buffer the first. Third, program 
execution time is prolongated, due to the obligatory write access 
to the buffer. Under unfavourable conditions/ the access can the 
three times longer compared to direct write access in the EEPROM- 

SUMMARY OF THE INVENTION 



Accordingly, it is a primary object of the present invention to 
overcome the drawbacks mentioned above and to provide a unique 
method and system for the secure management of data in chip card 
applications- 

These and other objects of the present invention are accomplished 
by storing the data in logical structures/ i.e, record oriented 
data structure. Each of these records contains a status byte in 
addition to the data contents* The status byte indicates whether 
this record is the presently valid one or not (primary 
attribute} • Further, the record contains a sequential number 
(synchronization number) , which is used to establish rhe join 
with the files to be synchronized (secondary attribute) . From the 
set of files to be synchronized, a key file is defined whose 
present record contains the presently valid synchronization 
number* The other file is designated as secondary file. 



According to the present invention, a method and system for data 
management in a chip card EEPROM is provided which secures data 
even in the case of interruption or abortion of a sequence, such 
as power failure etc, without the need of a buffer. The 
invention allows that two files of the chip card stay consistent 
if an interruption occurs while updating the files by storing the 
information concerning the creation of the consistency together 
with the data. By this, data security is guaranteed even over 
sequences of commands. The invention comprises a special data 
fonoat and a search algorithm to determine the valid file 
contents and to correct data which is written incompletely due to 
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interruptions or laemory errors. The record search algorithm 
renders a special recovery routine for data contents after an 
interruption superfluous. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates the structure of a data file according to 
the subject invention; 

Figure 2 is an illustration of the structure of the logic records 
contain in a data file in accordance with the subject invention 
as shown in figure 1. 

Figures 3a and 3b illustrate a sequence flow for an arbitrary 
number of files 1 to n in accordance with the subject invention. 

DETAILED DESCRIPTION OF THE INVENTION 

First, the invention is illustrated for the case of two data 
files. Figure 1 shows the structure of each file - key file and 
secondary file - according to the invention. Figure 2 illustrates 
the structure of each record. According to figure 1 each file 
consists of an indication of the number of logic records^ the 
size of logic records and a subsequently nurtibered amount of logic 
records. Each of those records consists of an indication of the 
record status r a synchronization niimber and the data contents ^ as 
illustrated in figure 2, 

When updating the files that were involved in a transaction that 
was interrupted, the following algorithm is used: 

1 * determine the current active logic record and the (working) 

record of the key file to be written; 
2. set the synchronization number of the working record of the 

key file to the synchronization number of the active record, 

and increase the synchronization nuiftber of the present 

record by 1 ; 
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3. write the new data of the key file in the working record? 
4* change the record status of the working record of the key 

file to "active"; 
S ■ « * • 

6. execute a complete update of the secondary file, including 
definition of the new active records; 

7 . 

8» change the record status of the old active record of the key 
file to "inactive". 



Following this algorithnir it can be ensured for the key file and 
the secondary file that new data contents become valid by one 
single (atomic) write operation on the key file (step 8 in above 
algorithm) , and that no inconsistant interstages of the data 
contents occur. The only requirement for this is that the 
determination of the active logic record and of the working 
record is performed according to the following record search 
algorithm for the key file: 



1. beginning with the first physical record, search for the 
first record whose status is "active"; 

2. in case the first physical record and the last physical 
record of the file are marked "active** ^ then the last 
physical record is the active one; 

3. if there is no record found marked as active, then set the 
first physical record to "active"; 

4. define the physical record following the active one as 
working record; 

5. in case the active record is the last physical record of the 
file^ then the first physical record of the file becomes the 
working record. 

The following is the record search algorithm for the secondary 
file: 

1. beginning with the first physical record, search for the 
first record whose status is "active"; 
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2. in case the first physical record and the last physical 
record of the file are marked "active", then the last 
physical record is the active one; 

3. if there is no record found marked as activor then set the 
first physical record to ''active"; 

4. compare the synchronization number of the determined active 
record with the synchronization nuinber of the active record 
of the key file; 

5. If the trial fails, mark the record as "active" whose 
synchronization number corresponds to the synchronization 
nuiciber of the active record of the key file; 

6. define the physical record following the active one as 
working record; 

7* in case the active record is the last physical record of the 
file, then the first physical record of the file becomes the 
working record. 

The method described above can be extended to an arbitrary nuinber 
of files without any changes to the algorithms. In this case, all 
further files are classified secondary files. Hereinafter, 
referring to figures 3a and 3bi the method according to the 
present invention is explained for an arbitrary nimber of files, 
wherein one record in one file has the following structure: 
Flag Ptrl Ptr2 Ptr3 Data 

The Flag indicates whether a record is active ("A") or inactive 
("I") ♦ A record can have the 'A* flag set but still is not 
considered to be valid: if the Ptr2 field does not point to the 
begin of the record/ the record is still part of a chain to 
records in other files and 'under construction'. Only when Ptr2 
points to the begin of its own record it can be said for sure 

that the chain has been unlinked and all files are synchronized • 
A record with this condition and with the flag set to 'active* 
could be called 'fully active* - 

The files are cyclical files, an arrangement which is often 
described as a ring buffer. They are record-oriented/ in other 
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words, there always is one 'current record' from the operating 
system's point of view. The current record does not have to be 
the same as the 'fully active' record. 

The following sequence of events describes how an arbitrary 
number of files can be updated and at the same time ensure that 
either the current (old) information in all files remains 
accessible or the new information is guaranteed to exist in all 
files. The number of pointers can probably be reduced and the 
scheme be greatly simplified if we operate only on a well-defined 
set of files which never changes « 



a* Append or update the Data field of a record in the first 
file: 

al T^pend a new record in file 1 and copy the data from 

the current record to this new record* Modify the data 
as required. The appended record becomes the current 
record (from the operating system's point of view). The 
previous record remains 'fully active' (from the safe 
update mechanism's point of view), list write to Ptr2] 
A power' failure at this point still leaves the previous 
record 'fully active'. Ptr2 in the current record 
points at this record because it has been copied in 
step (al) from the previous record in this file where 
it points to the begin of this same previous record, 

a2 The new (current) record is flagged 'inactive'. [1st 
write to Flag] Step a2 can also be accomplished 
together with al in one write operation, 

a3 Ptrl is set to a value which signals the end of a 

Linked list (no linic to a subsequent file) list write 
to Ptrll 

a4 Ptr3 is set to a value which signals the end of a 

linked list (the first file does not have a link to a 
previous file) [Ist write to Ptr3] . 
A power failure during this process still finds the previous 
record as before: fully activer no changes • Any changes to the 
new (current) record in file 1 remain therefore invisible and are 
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b. Append or update the Data field in the second and 
subsequent files: 

bl Append a new record in this 2nd, 3rd/ etc, file and 
copy the: data from the current record to this new 
record. The appended record becomes the current record* 
Modify the data as required and flag the new record as 
•inactive' [1st write to Ptr2] 

A power failure at this point still leaves the previous 
record 'fully active' » Ptr2 points at this record 
because it has been copied in step (bl) from the 
previous record in this file where it also points to 
the begin of this previous record. 

b2 The new (current) record is flagged 'inactive*. [1st 
write to Flag] Step b2 can also be accomplished 
together with bl in one write operation. 

b3 Ptrl is set to a value which signals the end of a 

linked list (no link to a subsequent file) [1st write 
to Ptrll . 

hi Ftr3 is set to point at the new (current) record in the 
previous file. This establishes a backward link between 
the files. [1st write to Ptr3] . 

We are new done with the new (current) record in this 
file 2, 1, etc. File 1 and file 2 can still fall back 
to their previous records which are * fully active*. 
Ptr2 in the current record should make automatic 
internal backtracking easy, or simply use the options 
in the Read Record coiwDand to address the previous 
record, 

b5 Ptrl in the new (current) record in the previous file 
is set to point at the new record in this file. This 
establishes a forward link from the previous file in 
the chain to this file. [2nd write to Ptrl] 

b5 The flag in the new record in the previous file is set 
to 'active' [2nd write to Flag) » 

However f Ptr2 of the new record in the previous file 



still points at the previous record in the previous 
file. Therefore the new record cannot becorae 'fully 
active' yet. 

A power failure during this process still finds the previous 
records in the file(s) as before: fully active, no changes. Any 
changes to the new records in these files 2, 3, etc- remain 
invisible and are discarded, 

c* ...and so on with any additional files until we have 
appended or updated all data in all files which heed to be kept 
in synchronism. There are soroe final actions which are unique for 
the append or update of the (last) file. 

cl Set the Flag field of the last appended (current) 

record to * active ' . t2nd write, 1st was 'inactive* in 
step al or bll . We can save this 2nd write if we 
already know that this is the last file when we append 
the new record and modify its contents as we copy from 
the previous. 

A power failure at this point Leaves an incomplete 
chain behind. An incoiaplete chain (one where the last 
record in the chain is not marked as 'active' AND Ptr2 
does not point at the same record) is plainly discarded 
and we fall back to the 'fully active' (previous) 
records in all files. 
c2 Set Ptr2 of the new (current) record to point at the 
begin of the current record. This on© writd makes the 
new record in the last file 'fully active' and enables 
the recovery. Now we have the previous record in the 
last file which is 'fully active' and the current 
record which is also 'fully active** 

A power failure after this single write operation has 
no adverse effect because we can now recover. 

Recovery 

We can repair a power failure after step (cl) in two ways: either 
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we can begin again from scratch to update all files; all the 
previous records still hold the old infonoation and a new attempt 
to update the files synchronously laight just as well succeed this 
time. When we append new records in the files r then we copy the 
Ptr2 fields also to the new records which lead us back to the 
•fully active* record in each file. 

Alternatively, it is possible to roll forward and now make all 
the new (current) records in the chain fully active, which is 
much more convenient : 

d. Check for need to recover from a power failure: 
Check file #1 if there is a current record which has the 
'active' flag set AND Ptr2 does not point to the Flag field of 
the same record. If we find such a record in file 1, then it must 
have been added in step (a) above. If there is no such record, 
then we do not have to recover from a power failure. 

Recovery^ linked list was bfuilt Quccessfully 

We start from the end of the chain to make the records fully 
active • The chain becomes shorter v/ith each successfully new 
record activation until Ptr2 in the new (current) record in 
file 1 points to the Flag field of the same record and is 
then also 'fully active'. 

Starting with the not 'fully active* record found in file Ir 
follow the chain along the Ptrl links until Ptrl signals the 
end of the chain where the Flag field is marked as 'active, 
last in chain' . 

dl If the new (current) record in the last file in the 
linked list is 'fully active \ search the file for 
another fully active record and, if one is found, set 
the Flag there to 'inactive' [3rd write to Flag], 
Continue with step (d4) and unlink the file. 



This was the last file in the original chain which has 
two 'fully active' records, or we must have had a 



failure during recovery between steps (d3) and (d4) 
after this file was completely done but was still 
linked to the previous file, 
d2 If the new (current) record is 'active' but Ptr2 does 
not point to the begin of its own record/ follow Ptr2 
to the previous record in the last file. Check if the 
previous record is 'fully active'; if yes, set the Flag 
there to inactive I3rd write to Flag! » 

If power fails after this step, then we come to the end 
of the chain again but notice that we do not have 
anything to do any more with the previous record* 
d3 Modify Ptr2 in the new (current) record in the last 
file in the chain that it points at the begin of the 
same record. [2nd write to Ptr2] . This makes the new 
(current) record 'fully active' - 

A power failure at this point leaves the new (current) 
record in the last file flagged as 'fully active*- When 
recovery is restarted, it runs into step (dl) and skips 
(d2, d3, d4> , 

d4 Unlink the currently last file: set Ptrl in the 

previous file (Ptr3 brings us there) to a value which 
indicates the end of the linked list, 
A power failure at this point leaves the linked list 
shortened by one file- The recovery process can simply 
begin again, finds the previous file is now the last 
file, and falls into step (d2), 

d5 If power stays on and we continue: Go backwards along 
the Ptr3 linked list to the previous file and repeat 
steps (dl^ d2/ d4, d5) until Ptr3 signals that we are 
at the begin of the chain in file I. 

Recovery, linked list waa not built auceessfally 

el If the new (current) record in the last file in the 
linked list is active but Ptr2 does not point to the 
begin of the record, we may have been interrupted after 
(al)# (bl) or (cl) . Set the flag to 'inactive'. 
A power failure at this point leaves the pointers 
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intact (Ptr2 is needed) • We can re-enter the recoveEy 
routine and fall into (e2) • 
e2 If the new (current) record in the last file in the 

linked list is inactive and Ptr2 does not point to the 
begin of the record, we have been interrupted after 
steps (a2), {b2} or (el). Otherwise go to step (e5) . 
Now follow Ptr2 to the previous record in this file* We 
are m the old (previous) record and fall back to its 
old data. Set Ptrl to point at the new (current) 
record- We must be able to find it yet. Note; Ptrl is 
no longer part of a chain in the old record and can be 
reused. 

A power failure at this point lets us restart and we 

fall into step (e2) again. 
e3 Set the flag in the old record to *active*r recovered' 

to differentiate it from a fully active last record in 

a chain which is described in steps dl..d5. 

A power failure at this point lets us restart the 

recovery and we fall into (e2) again. 
e4 Make this old (previous) record in the last file the 

current record from the operating system's point of 

view* 

A power failure at this point leaves the linked list 
with a current record in the last file which is 
^active*, recovered' and Ptr2 points to the begin of 
the record. This file has been successfully recovered 
but we have not unlinked this last file yet. 
A power failure at this point means that we re-enter at 
(e2) and fall through to (eS) . 
e5 If the old (current) record in the last file in the 
lin)ced list is *active, recovered' and Ptr2 points to 
the begin of this record, then unlink this currently 
last file from the chain. Tollow Ptrl in the current 
record of the last file to find the now defunct "new" 
record which contains a valid Ptr3 with a backward file 
link. Set Ptrl in the previous file to a value which 
indicates the end of the linked list* The previous file 



■30-Jt^Q9 : e^^^£^smn^mm 07U785521 

- 13 - 



DE9-1999-0076 



is now the 'last file' ► Continue with step (el) until 
Ptrl indicates that we are at the begin of the linked 
list file 1- 

This method works exactly the same, independent of several 
important criteria: 

• It is immaterial how many different files are involved and 
need to be kept in sync, 

• It is imiciaterial in which sequence the programmer touches 
the secondr third, etc. files^ i.e. how a specified sequence 
flow defines the order in which parameters are updated. 

• All what is needed for recovery is the knowledge which file 
is updated first in such an atomic sequence. Check this file 
#1 if there is a record which has the 'active' flag set 
where Ptr2 does not point to the begin of the same record* 
If there is no such recordr then we do not need to perform 
any recovery. 

• The method writes at the most three times to the same 
addresses (flag) . 

The following are commented excerpts from a computer program 
implementing the method according to the present invention for a 
purchase sequence. If run on a computer, such a computer program 
performs the steps of the method of the present invention. 

1. Atomic sequence flow - initialize PSAM 
Work with file EF_PLOG: 

1. Search from the begin of the file until the first current 
record (marked active with 01) is found. 

2. Mark the following record with 00. This becomes our working 
record but it remains inactive. 

3. Copy all other data fields from the first found record to the 
working record. 
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EF-PLOG[(lst found curr ) +1] . curr = '0' 

new record inactive 
Er-PI<OG( (1st found curr)+13.aai other= BF-LOG[lst found currJJ.all other 

copy fields 

\ 

Kow use the working cecord in EF^iOG: 

Update the fields TRT, MTOT, NT, NIT^ NC, NCR in this record as required. 

This record update operation is handled in the MFC 4,1 OS* 

EF_PL0C5[(lst found curr)+ll.TRT = PurchaselnitializedE (we skip the 

PurlnitialiaeStartedE state!) 
EF^PLOCJI (1st found curr) +1] • WTOT ^ 0 

EF_PW>Gl(lst found curr)+ll.KT = EF_LOG [ (curr) 1 . NT+1 

EF_PLOG[(lst found curr)+ll.KCR ^ NCR (internal) 

EF_PLOG[(lst found curr)+l].NC = EF_TM(NCR) [ (curr ) J .NC+1 

logged here 

BF_PL0G[(l3t found currJ+l).NIT = EF_TM{NCR) ( (curr J ] .NIT-*-l 

logged here 

BF_PLOSnist found curr) +i] .xxxiep = (from conansuid parameters: CURRiep, 

FLI Di ep p BALi ep r I Di ep , NT ip » I Dpda , 
EF_PIiOG{ (1st found curr) +1] , DATE, TIME « (from coinmand paranteters) 
ID_PI>A 

The updated record in EF_PX*OG has not been activated yet! The NIT increment in 
EF_TM comes later here in step 1 

If power fails before or at this point, then we fall back to the current active 
record in EF^PLOG and keep the old information - which is still ok. The state is 
also that of the old record. The procesd as described above can therefore be 
initiated again. 

If everything went well, proceed in a similar way in EF^TU(x} . 

4, Search from the begin of the file until the first current record 
(marked active with 01) is found* 

5. Mark the following record with 00* This becomes our working record 
but it remains inactive* 



Nfow use the inactive working record in BFjQl<x} 

Copy the already incremented field NIT from the log file. 

EF_TM(NCR) (Xst found curr)+l) - '0' 

new record inactive 

If power fails here, we fall back to the old record in EF_PIiOG and in 
EF_TM. OK. 

EF_TM (NCR) Hist found curr)+l] ,NIT * EF_LOG[ ilst found cucr)+lJ.NIT 

counted here 
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SF_TM(NCRJ [ (Ist found curr)+l],NC » EF_LOG[ (Ist found curr)+ll,NC 

counted here 

The MIT and NT actudl counters are incremented now but the record ia 
atiXl inactive* 

l£ power fails at or before this pointy then we £all bac}c to the 
currently active EF^TM record with the old information. This is still ok 
because we also fall back to the old EF_PLOG record with its old TRT 
state*. However, after EP_PLOG is activated (which is done below) we are 
forced to activate BF TM a3 well. 



Kote: TET's concept did not activate the BF_TM working record at this time which 
means that it needed to be done in Complete Purchase and Abort Purchase. 
However, if we don't activate it here« then the if statenvent in Complete 
purchase fails- Just for reference, here is how ic looks if we activate the 
Er_TM record right here: 

work with file EF_TM(x) : 

if EF^TMSKCR) [ (Ifit found curr)+l].NIT = EF_PLCK5[ (1st found curr)+13 .NIT 
BF_TM(NCR> [ (1st found curr ) -f 1) - curr = '1' 

new record active 

If power fails here, then we have two active records in EF_^TM but 
hopefully find the same first active (old) record as before. Consider 
the special case of Wrap-around in the circular file! thid means that we 
still fall back to the old data. OK. 



Sf jrM(NCR> [ (1st found curr)],curr - ♦0» 

old record inactive 

Now we have one active record in EF^TM with the correct NIT which 
matches Er_PLOG. If power fails here* then the (old) active record in 
BF^tLOG indicates that we are still in state PurCorapletedB or 
PurAbortCoxnpietedE: we repeat the command **Initialize PSAM for Purchase^ 
with the steps above and start new records in EF_PLOe and in EF^TM, but 
now copy the already incremented NIT value from the (new) active record 
in EF_TM to the working records Then we iAereraent KIT attothvr tia* in 
this working record and probably activate it (and the record in 
EF_PLOG) . 

The still Inactive record in EF^PLOG and the active record in EF_TM are 
now in sync. 

If everything went well, make the new record in SF^PUOG the current record* (Not 
without doing the same with EF^^TM. . . ) 

ZRXi( 



- 16 - 



+4:9 89 2Q39^ r^^^^<^-<<^^<^y^:. 
DE 9- 1 9 9 9 - 0 b7^6'"""^""""" 



EF_LOG[(lst found curr) +1) -curr « '1' 

new record active 

If power falls now, then we have two currenr = active records. We always 
look only for the first, i*e. we hope to find the old one. Consider 
wrap-around effects in a circular file* Ne fall back and lose the 
information in the new record. This is still ok. 
EF^U3G[ (1st found c:urr)]-curr = '0' 

old record inactive 

} 

If power fails now, then we find a new active record in EF_PLOG with the TFT 
state = PucInitializedE and the NT, KIT log values as incremented, and an also 
active new record in BF_TM with the WIT counter incremented. 

Now we cannot fall back to the old informtion in EF^PLOG any more. We are now 
forced to either complete or abort the purchase, 

2. Atonic seqaenctt flaw - Credit PSittC for l^arehase 

This is another time that the PSAM files are updated. This command can be 
repeated* start a new record in EF^PLOG for each execution. We enter the cc»rcrtand 
with EF_PLiOG and EF^TM values in sync. 

work with file BTJ^JUOOt 

1. 3ea£Ch from the beqin of the file until the first current record 
(marked active with 01) is found. 

2. Mark the . following record with 00, This becomes our working record 
but it remains Inactive » 

3. Copy all other data fields from tne first found record to the 
working record. 

SDR{ 

EF_PLOG[(lst found curr ) +1] * curr 
EF_PL0G(<X6t found curri413,all other 
} 

Er_PLOGE(lst found curr)+l).TRT = Purchasings 

appetnd record 

EF_PL0G[(l3t found curr)^ll.all other = BF^IiOGt (lat found curr)].all other 

copy fields 

EF_PLOG[(lst found c-arr)+l] .mOT += MPDA 

update values 



new record inactive 
= EF_I.OG[{lst found curr)+l]»all other 

copy fields 



CV. VU\:fcit-A-MlJfcNCHbN 055 



:ao-] 



r99 



170552 



+49 89 23994:$ 



- 17 - 



DE9-1999'00-7b' 



EF PliOOtllst found curr>'H].aAL 



-= MPDA 



logging 



If power fails here, then we lose the purchase amount and rei&ain in the 
previous sate: PurlnitializedB if this was the first Credit Purchase 
eoRsnand, Purcha9ing£ if it was an incremental conanand. In case 1 we must 
continue with Abort Purchase, in case 2 with Conplete Purchase. 

Work with file E7jRf<x) < allocate a new working record) 

BF_TM(NCR| I (1st found curr)+ll.TM 
EP TM(IICR) C ilst found curr)l,TM 



+ EF LOG [< let found curr) +1] .MTOT 



old value 



update 



If power fails now, then the amount TM and NIT in the active record in 
EF^TM are in sync with the active record in EF_PLOG but TM does not 
include the last purchase ainountr only the inactive record reflects 
this. We could either activate the EF^TM record here - then we have to 
add MPDA each time. Or we leave the activation to the following cononend 
"Complete Purchase" - then we have to add MTOT here. 

There is a current inactive record in EF^PliOG in state PuxchasingE with 
updated MTOT and BAL^IEP fields. Activate it now* 



EF_PIX>G( (1st found cutr>4-l) *curr = "1* 

new record active 

If power fails now, chen we have two current = active records « We always 
look only for the first » i.e. we find the old one* We fall back and lose 
the information in the new record. This is still ok. 

EF_PLOGt(lst found curr)]-curr '0' 

old record inactive 



Atoaic d«<iueace flow - Coa^lete Pvizehaae 

This is the last step where the still disjunct file contents of EF_PLOG and 
KF^TM need to be brought in sync. The command uses a new record in EF_PIiOG to 
work. The TRT state in the new record in EF_PliOG must be set to PurCompletedE. 
Check the values in the still inactive new record in EF TMIk) and activate it. 



Work with file SIM?L09: 

1. Search from the begin of the file until the first current record 

(marked active with 01) is found. 



tJu - ay : Mi^^J,...^.^..... 07 1 1 7855S 

- IB - 



+49 89 23994^/^:^" irH^a 

DE9-1999-0^fW 



2- Mdirk the following recced with 00, This becomes our working record 

but it remains inactive. 

3. Copy all other data fields from the first found record to the 

working record. 

HDHt 

SP_PLOG((lst found curr) +1] . curr ^ '0' 

new record inactive 

EF_PIiOS[ <lst found curr)+l].all other - EF_L0G[(i3t found currH-all 

other 

copy fields 

J 

1. Set the final state in the working record of EF_PLOG. This record is 
still inact2.ve. 

2 . If the NIT in EF_PIjOG i3 the same as the value in the still inactive 
working record in EF_TH(x), then update the TM and KIT values in the 
working record. Otherwise skip this step. Fall back* 

3. If the NIT in EF^PLOG is the same as the value in the still inactive 
working record in EF_TM(x), activate the working record in EF_TM<x) , 
Otherwise skip rhis step* Fall back. 

EF_LOGt<lst found GurrJ+l!-TRT = purchaseConq^letedE 

final state 

If power failSp then we fall back to the now active new record in 
BF_PLOG with state PurchasingE and NIT incremented and the still active 
old record in EF_TM with NIT not incremented. 

ROTiark: The NIT in the two currently active records in ef_PLOG and EF_TM(3C> must 
be in sync from a previous command "Initialize PSAM for Purchase". Only TM 
in BF_TM is left to be updated* 

Work With file EFJXU(Jc) 

if BF_TM(NCK) [ (1st found curr) -t-l] .NIT == EF_PXX)Gt (Xst found curr))«NlT 
EF_TM<NCR> I (1st found) +1] .TM = EF^TMCNCR) ( {1st found curr) 1 ,TM 

+ BF_L0Gl(l3t found curr)]*MTOT 

If power fails here, then we fall back to the still active records in 
EF^PLOG and EF_TM and repeat the command. OK. 

EF_tM(NCR) ( (1st found curr ) +11 . cure » *l' 

new record active 

If power fails here, then we have two active records but hopefully find 
the same first active (old) record as before. Consider the special case 
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of wrap-around in the circular filet This means that we 6till fall back 
to the old data. With these assunqptiona, the {HDR} makes sure that the 
second active record is first deactivated again if we execute Conq;>lete 
Purchase another time. 

EF_TM (NCR) Hist found curr)lj.curr = '0' 

old record inactive 

Now we have one active record in EF_TM with the correct TM and a MIT 
which matches EF PliOG. If power fails hexe, then the (old) active record 
in EF^Pl*OG indicates that we are still in state PurchasingE; we repeat 
the connnand "Complete Purchase" with the steps above and start a new 
record in EF_TM, but now copy the already adjusted TM value from the 
(new) active record in EF_TM to the working record. Then we add MTOT 
another in this working record and activate it which means that the 

service agent gets more money. 

Activate the working record in KF^FZiOGs 

EF^LO^Klst found currJ+l] -curr - '1* 

new record active 

If power fails now^ then we have two current = active records. We always 
look only for the firsts i-e. we find the old one. We £all back and lose 
the TRT state information = PurchasingE in the new record. This is still 
ok^ ^ust repeat the ccmmand. 

EF_LOGI(lst found curr)],curr = '0' 

old record inactive 

\ 

If power fails here, we have a correct set of data in EF_PtOG and 
EF_TM(x) . 

4. AtosniQ sequence £Iow - Abort Purehaae 

This is the last step where the TRT state in EF_PLOG must be set to Pur 
AbortCoxnpletedE* It is not necessary to synchronize two files since we have 
activated the new record in the "Initialize PSAM for Purchase" coromand. 

The command uses a new record in EF^FLOG to work. 

Work with file Br_VZ<OG: 

1. Search from the begin of the file until the first current record 
(marked active with 01) is found* 

2. Mark the following record with OO. This becomes our working record 
but it remains inactive. 

3. Copy ail other data fields from the frist found record to the 
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working record. 



BF__PLOG( (1st found curr ) +1] . curr 



EF_PLOG[(lst found curD+D-all othec - 



new recozd inactive 
BF_IiOG[(Xst found curr)j.all 
Other 

copy fields 



1. Set the final state in the working record of EK^PLOG. This record is 

still inactive 

Er_IiOG({lst found curr)+l).TRT =■ PurAbortCowpletedE 

final state 

IF power fails here, then we fall back to the now active new record in 
EF_E>LOG <with state PurlnitializedE and NIT incremented) and the still 
active old record in EFJTM, OK* 

Activate the working record in BF PLOOz 

EF_LOG[Ust found curr)41] ,curr ~ 

new record active 

If power fails now, then we have two current - active records. We always 
look only for the first, i.e. we find the old one WITH STATE 
PurlnitializedE. He fall back and lose the information in the new record 
but can repeat the Abort Purchase command. This is still ok. 

Er_LOG[{lat found currJJ.curr = *0' 

old record inactive 



} 



If power fails now, we have an active record which reflects the correct 
counters, etc* in EF FLOG, 



VSMJA load ttegrsence 



Atomic aeqomce flow - Debit LSAH 



Work with file EF_LLOG: 

1. Search from the begin of the file until the first current record 

(marked active with 01| is found. 

2- Mark the following record inactive with 00. This becomes our working 
record. 

3, Copy all data fields from the active record to the working record. 

4. Update the working record* 



CV . VOM : E=PA JVH JENCHEOS! 05 



^99 



- 21 - 



+49 89 2399^1^ 



BDR( 

} 

EF^LOGl tlst found curr) .TRT 



: LoadsdS 

final strata 

: MLDA 

logged here 
^ EF_LOG[(lst foutid curr)l,NT + 1 

logged here 
: EF_TM(NCR) [ {1st found curr) ] .NIT +1 

(logged here) 
^ EF_TM{KCR) [ (1st found currJJ.NC + 1 

(logged here) MWi 

^ WCR 

(from coirmanct parameters) 
A power failure find EF_LLOG updated but TM, NIT, NC in EF_TM (NCR) are 
not. The conmand cannot be repeated- We have to fall back to the old 
data in the active record in EF LLOG. This is ok. 



EF_LOG[(lst found curr) +11 •KTOT 

BF_LOGl(Xat found curr)+lJ.NT 

EF_LOG[{lst found curr ) +1] .^3IT 

BF_I*OGl(lst found cucr)+l].NC 

Er_LOG[(l5t found cucr5+l].NCR 
EF_LOGt(lst found curr)+l] .XXXiep 



If everything went well, work with EF_TM{x) : 

1< Search from the begin of the file until the first current record (marked 
active with 01} is found* 

2. Mack the following record inactive with 00- This becomes our working 
record. 

3. Copy all data fields from the active record to the working record. 

4. Update the working record with data which have already been logged in 
EF JULOG 

new record inactive 
= BF_I*OG[(lst found curr)+ll.NIT 

counted here 
= BF_LOG[ast found curr)+l].NC 

coiinted here MWi 
= EF_TM(NCR) I (1st found curr)+l].TM 

+ MLDlA 

accounted here 

If power fails at this pointy then we fall back to the currently active 
record in EF_TM. The working record in EF^LLOG has also not been 
activated yet, so both files fall back to the old infonoation- 

if (EF_TM(NCR) { (1st found curr)+l] .NIT = EF_IiOG({lst found curr ) +1J •KtT) 

( 

EF_TM(curr/flid) [ <lst found curr} +1 1 - curr - '1' 
EF_TM(curr/flid) [ ilst found curr>l.cucr - 'O' 

} 



EF_TM(NCR) t (1st found cure) +1] . curr 
EF_TM(NCR) I (1st found curr) +1] .KIT 
EF_TM(NCR1 I (1st found Curr)+1].NC 
EF TM(NCR) ( (lat found curr}+l] »TM 
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EF_LOG{(lst found curr > +1 1 . curr = '1' 

new record active 

If power fails. now, then we have two current = active records » We always 
look only for the first, i.e. we find the old one, We fall back and lose 
the information in the new record. This is still oJc. 
EF_LOG[ (1st found Gurr)]»curr = '0' 

old record Inactive 

) 



claims 



I. Method of securely managing EEPROK data files in order to 
restore data after abortion of a write operation, the data 
being stored in a record oriented data structure with each of 
the records containing a status byte in addition to the data 
contents - 
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ABSTRACT 



Method and system of securely managing EEPROM data fiXes in order 
to restore data after abortion of a write operation, the data 
being stored in a record oriented data structure with each of the 
records containing a status byte in addition to the data 
contents . 
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logic record 2 
logic record 3 

Figure 1 



record status 
synchronization nuniber 
data contents 

Figure 2 
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